IBIS Macromodel Task Group Meeting date: 06 October 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan * Todd Bermensolo Rui Yang Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SAE ITC * Jose Godoy SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that the agenda had stated that we will need to switch the meeting to Microsoft Teams in the future. However, in attempting to log in to today's meeting, people discovered the Webex had been cancelled. So today's meeting was held with Teams. Look for the Teams meeting link in future agendas. - Arpad noted that he had removed the previous item #7 from the agenda list, since we had discussed Intel's presentation from the most recent IBIS summit. In its place, he had added a topic for a new GDDR6x technology Randy had asked to discuss. ------------- Review of ARs: - Michael to send a fourth draft of the [Clock Pins] BIRD proposal. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the September 29 meeting. Randy moved to approve the minutes. Michael seconded the motion. There were no objections. ------------- New Discussion: New Clock-Data Pin relationship BIRD [Clock Pins]: Michael Mirmak briefly summarized the fourth draft of the [Clock Pins] BIRD, which he had sent out prior to the meeting. He noted that this version focused on the reintroduction of the third column. The third column is for future expansion, and the only permitted entry at this time is "unspecified", which is case-sensitive. This gives us something other than "NA", but it is still a fixed allowed value. Text now states that the first and second columns contain pin_names, but it no longer specifically says "clock" and "data" pins. Instead, it states that the pin in column 1 clocks the pin in column 2. There is no checking of directionality other than the sentence about the allowable Model_types. Michael also noted that he had added one final sentence prior to the example. It states that this proposal is compatible with Timing_location. Walter said that one issue is the numbers themselves (min-max delay, rising, falling, etc.), and we all know that is complex. Walter said he'd be willing to share the numbers from their timing models when we get to that discussion. He said the other issue is "what kind" of relationship (clock to out, setup and hold, for clock forwarding on the write it is skew between clock and data), and that information is independent of the numbers. Walter said he would prefer to have four columns. The third could be the relationship, and the fourth could be a place holder for a future pointer to a data structure fully defining the relationship. Walter acknowledged that he'd missed the last few meetings and may have missed some discussion. Michael confirmed that we had discussed the second issue at great length in the past few meetings. He had originally included a third column providing only the names of three relationships, but he had encountered demands for more detailed information on exactly what the relationship names meant. Rather than get bogged down in attempting to provide definitions yet keep the terms vague enough to be fully defined later, he had dropped the relationships and gone with the "unspecified" placeholder column. Walter said he was fine with approach if we had already discussed the options. Bob said that Walter had a good point about the complexity of defining the relationships and providing all the numbers. He said he would ask Steve Parker (webmaster) and Mike LaBonte to resurrect the links to the RAIL (Rules Augmented Interconnect Layout) specification that had been developed years ago. He noted that it had carefully defined many relationships. Bob said this current proposal provides a template for relating two pins, but the entire relationship may take 5 or 6 more keywords and won't be a simple BIRD. Bob noted, as he had in the last meeting, that he preferred "NA" instead of "unspecified". Michael said we had discussed it last time and put considerable thought into "NA". He said the goal here is to leave it so the tool or user can fill in the details for now. "Unspecified" says that the relationship is not specified. "NA" could be taken to imply that no relationship exists, and we may need to have "NA" available later for that meaning. Bob agreed that Michael's logic was sound, but he said he'd prefer the first letter of "unspecified" be capitalized. Michael changed all instances to "Unspecified" and noted again that this would be a case-sensitive comparison. Bob stated that this proposal now allows chains: al clocks a2, a2 clocks a3, a3 clocks a4, etc. Michael agreed and said the only remaining restrictions are that an entire row can't be repeated, and that the same pin can't appear in column 1 and column 2 on the same row. Arpad asked if loops were possible, for example a4 could then clock a1 in Bob's previous example. Michael said nothing in the syntax prevented it. Bob said he had brought up a loop at the previous meeting as a pathological case, but that a circular loop actually didn't make sense. Walter said one could look at a Rambus clock to see how complicated this could get. Arpad asked if the group felt this was ready for Michael to submit as an official BIRD. Randy moved to recommend Michael submit it. Curtis seconded. There were no objections. Michael took an AR to submit the BIRD to Randy for posting. Bob noted that it would likely be assigned the number BIRD208. GDDR6x Discussion: Randy reviewed his presentation "GDDR6x Introduction". Randy noted that GDDR6 is a graphics DDR memory technology that has been around for a while, and GDDR6x is a new super speed variant. It was developed with Nvidia. The presentation summarizes publicly available information on the new memory signaling technology. The goal of the presentation is to spur thought about IBIS modeling support requirements. slide 2 - What's new: - Link to a technical brief with more details - Makes use of single-ended PAM4 - Pushes single-ended I/O beyond 16Gbps, targeting up to 32Gbps slide 3 - PAM4: - Same old PAM4, just single-ended this time - NRZ has broken down beyond 16Gbps, but PAM4 can achieve 32Gbps slide 4 - Tx/Rx specs: - Tx and Rx will have Equalization - 1.25V or 1.35V VDD/VDDQ - VDDQ terminated bus - First product 19Gbps or 21Gbps, in future moving beyond that - Gray coded data - 3 Rxs, 3 VREFD levels - 40 or 48 Ohm ODT Arpad asked if the VREFDs were provided externally or internally generated. Randy said it's internal, like DDR5, with registers set to provide 64 steps. Bob asked if termination was selectable or fixed. Randy said the 40 or 48 is selectable. slide 5 - Tx Impedances: - Tx implemented with 60 and 120 Ohm PU/PD legs. - The 4 combinations provide the 4 output levels. - Various swings based on VDDQ (1.25V or 1.35V) and Rx termination (40 or 48 Ohm). Arpad asked what the red resistors in the diagrams represent. Randy said they represent the termination value at the Rx. slide 6 - Clocking: - clock diagram shown (PAM4 operation shown, lower speed non-PAM4 also exists) - Similar to graphics: - base frequency clock - write clock - data itself Bob asked how this would fit it with BIRD208. Randy said you'd have a write- clock to data relationship. slide 7 - What is needed from IBIS?: - IBIS - New Model_types (I/O_PAM4, Input_PAM4, Output_PAM4)? - two-bit input stimuli? - Multiple Pullup/Pulldown curves? - 6 sets of V-T waveforms (one for each transition)? - [Driver Schedule]-like architecture? Randy said the last point wasn't strictly like Driver Schedule in the sense of various delays being applied, but that you'd be switching differently depending on the input bit pattern. Bob said if we need a dynamic change in behavior, we might look at Arpad's presentation from the 2018 SPI IBIS Summit. Arpad agreed this might be worth a look. He noted that they had implemented their examples with VHDL-AMS, but we could fold them into legacy IBIS. Randy said it would be helpful to review it. - IBIS-AMI - EDA tools - Support new Model_types for use in channel characterization? - Multiple edge responses? - Multiple bit responses for superposition schemes? - PAM4_*Threshold levels are VREFD levels. How are they to be set? - Special DC_Offset handling required? - Modify IBIS Section 10.7 (Modulation Reserved Parameters). Ambrish noted that for SERDES PAM4 in AMI we hadn't worried about different V-T waveforms. Arpad said as long as the step response is defined over the full range of the PAM4 signal swing, the one-level IBIS [Model] should work the same way here. Randy said he wasn't sure how SERDES PAM4 devices worked, but that the drivers for this GDDR6x are not at all linear over the entire range. Walter said he had some experience with single-ended PAM4 channels. He said people worry about the non-linearities, but that those effects tend to go away because of the high frequency losses. His experience suggested single-ended AMI allowed users to do good engineering analysis, the IR processing works, and we probably just have to lift the restriction that says that PAM4 AMI is limited to differential. He said he'd yet to see a case where non-linearities were important for NRZ, PAM3, or PAM4 at these data rates. He thought we could go a long way before we'd have to worry about different V-T tables for different transitions. Until then, we should just think about what changes might be required in the future. Ambrish and Walter agreed that we have a workable solution already. Walter asked if this would end up as a JEDEC standard. Randy said there had been a G5x, and he didn't think that had been standardized. He didn't think G6x would be standardized, but perhaps PAM4 might go into a G7. Arpad asked if Randy expected that only Micron and Nvidia would be making these G6DDRx devices or if everyone would make them. Ambrish answered that their IP group had asked them to look into it too. Bob asked about the resistor combination figures on slide 5. Randy said these were implemented inside the pullup/pulldown structures attached to the same location. Walter noted that the PAM4 symbols, referred to as -3, -1, +1, +3 on this slide, are more often called 0, 1, 2, 3 in the industry. - Ambrish: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Michael to send the [Clock Pins] proposal to Randy to submit as a BIRD. ------------- Next meeting: 13 October 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives